A Local Exchange Carrier (LEC) must typically manage two types of orders for communications services—service orders for its end-user customers and service orders for other LECs. For example, an end-user might request a basic telephone line with call waiting service from a local service provider (LSP) such as a competitive LEC (CLEC). Personnel associated with the LSP must in turn capture sufficient information from the end-user to allow the LSP to provision the requested service items. If the LSP does not own appropriate network, equipment, or other resources necessary to satisfy the end-user request, personnel associated with the LSP must interpret the request to determine appropriate service details and then use the details to create a standardized Local Service Request (LSR). The LSP communicates the LSR to an incumbent LEC (ILEC) or other network service provider (NSP), which owns the network, equipment, and other resources necessary to satisfy the end-user request. The NSP provides requested service items based on the LSR and the LSP completes the provisioning process with respect to the service items. The required format for LSRs, which is defined in Local Service Ordering Guidelines (LSOG) of the Ordering & Billing Forum (OBF), is frequently revised as competition between LECs evolves, new local services become available, or changes occur in the manner in which local services are requested. Existing ordering mechanisms often require extensive re-coding in response to such changes.
In addition, there has typically been little if any integration between the end-user ordering mechanisms and inter-provider ordering mechanisms. An Operations Support System (OSS) associated with the LSP will typically provide an end-user ordering module that links requested service items to the capabilities of NSPs, but doing so usually requires extensive input of LSP personnel. Inter-provider orders, such as LSRs between LSPs and NSPs, may often contain much more information than end-user orders or may specify similar information but in a different format. A possible solution is to force LSP customer service personnel to interact with end-users, perhaps multiple times, to obtain all information required for corresponding LSRs. This is undesirable, however, in part because it requires such personnel to have familiarity with the complex details of the LSRs and associated inter-provider ordering modules, practices, or both. This is often unrealistic given the difficulty many LSPs have in hiring and retaining proficient customer service personnel. In addition, some LSPs may not need inter-provider ordering modules or may not have purchased end-user and inter-provider ordering modules from the same company, such that the LSPs would not want information for LSRs unduly complicating their end-user ordering processing. Since CLECs may “error out” as many as fifty percent of LSRs due to incorrect or incomplete data entry, streamlining the LSR creation process is often a significant concern.
Furthermore, even where end-user and inter-provider orders contain similar information for a service item and present it in substantially the same format, LSP personnel may still be required to input information twice—once for the end-user order and again for the LSR. Moreover, the end-user is often inconvenienced as a result of multiple contacts with LSP personnel—once in connection with creation of the end-user order and again in connection with creation of the LSR. This inconvenience may be exacerbated if the second or any subsequent contacts come from LSP provisioning personnel that are skilled in connection with provisioning issues but, unlike customer service personnel, are untrained in interacting with end-users. Alienation of the end-user resulting from a poorly handled interaction with such personnel is highly undesirable.
Although techniques allowing LSPs to map certain information from their end-user orders to corresponding LSRs have been developed to lessen some of the difficulties described above, none have allowed the mapping to be customized and extended, in response to revisions to the LSOG or other particular needs, with little impact on end-user ordering modules. One or more of these or other deficiencies have made previous techniques for generating inter-provider orders, such as LSRs, from end-user orders inadequate for the needs of many LSPs.